home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14304 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.3 KB  |  89 lines
  1. Path: news.informatik.uni-muenchen.de!usenet
  2. From: Kurt Watzka <watzka@stat.uni-muenchen.de>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: #including everything
  5. Date: Fri, 12 Apr 1996 19:48:04 +0200
  6. Organization: Institut fⁿr Statistik
  7. Message-ID: <316E9754.237@stat.uni-muenchen.de>
  8. References: <829297481snz@setch.demon.co.uk>
  9. NNTP-Posting-Host: pc4.stat.uni-muenchen.de
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Mark Setchell wrote:
  16. > 
  17. > Does anyone have an opinion about how sensible it is to #include all
  18. > standard system header files in C programs? I work on a project with
  19. > approximately 2000 files and 500,000 lines of code and every file
  20. > has a long piece at the start like this:
  21. > 
  22. > #include <stdio.h>
  23. > #include <errno.h>
  24. > #if !defined(SGI) && !defined(HPUX)
  25. > #include <x.h>
  26. > #else
  27. > #if !defined(IBM_R2) && !defined(CRAY)
  28. > #include <y.h>
  29. > #endif
  30. > #endif
  31. > 
  32. > This is obviously a maintenance nightmare, porting is no fun either. I
  33. > am thinking of making a single include file with all system headers in
  34. > it (i.e. ones in <> as opposed to those in "").
  35.  
  36. A reasonable approach if all your compilation units use all "system" header
  37. files, _but_ this is the main reason for this problem, anyway.
  38.  
  39. Portable programs can be designed so that system specific stuff happens 
  40. in system specific compilation units, whereas portable stuff happens in
  41. potable compilation units. 
  42.  
  43. A compilation unit designed for POSIX directory access can use <unistd.h>
  44. without a bad conscience, whereas the implementation of a general purpose
  45. "key to value" map can use "standard" header files without any need to
  46. access system specific headers, because it simply does not need the 
  47. additional features provided by them.
  48.  
  49. The "long list of headers at the beginning of each file"-problem usually
  50. is a result of a bad modularization. In most cases, you should not need
  51. that long list of "system" headers.
  52.  
  53. > I suspect the disadvantages are:
  54. > 1) If it changes, all files have to be rebuilt - but that's ok it won't
  55. >    change often
  56. > 2) It may bloat the size of the binaries by including unused variables,
  57. >    but that's not really a problem on Virtual Memory machines, and the
  58. >    increase in size isn't much anyway.
  59.  
  60. If you _define_ variables in a header file, you do have a problem, and the
  61. problem is not increasing code size when the header is included in
  62. numerous compilation units.
  63.  
  64. Including all possible header files might add some symbol information to 
  65. your executable, but the additional size should not survive "strip" or a 
  66. "release build".
  67.  
  68. > 3) ???
  69. > 
  70. > Weighed against this, the advantages are:
  71. > 1) porting and maintenance become easier with only one file to maintain
  72.  
  73. I stronly disagree with this. There may be some "services" that have
  74. to include a system specific header file in the header file that provides
  75. the interface to that "service", but in general, non-portable includes
  76. should happen in non-portable compilation units. 
  77.  
  78. > 2) all system calls/functions are guaranteed to be prototyped
  79.  
  80. If your compiler does not support "forcing" prototypes for functions,
  81. you should think about changing your tool.
  82.  
  83. > Also, which system files should I #include?
  84.  
  85. In each compilation unit, the files needed by that compilation unit and
  86. no others.
  87.  
  88. Kurt
  89.